Rail building changes kovarex The problem with rail building is that it has too many states. It depends whether you start building the rail with shift, to use the ghost mode or not, and then it also matters whether you still hold shift, to ignore trees or not. Moving from manual building to ghost rail building means cancelling the whole rail building and starting it again with the correct modifier. The problems were reaching the surface from time to time, and Twinsen even drew a nice little state diagram of the rail building system. It kind of peaked with this bug report. After some time, it became clear that we should simplify it. This is a nice example, where we can talk about change we just released (0.17.29) in a FFF. From now on, instead of 3 modes (building manually, ghost building, ghost building + tree/rock removal), we have only 2 modes, where the ghost building without obstacle deconstruction is not available anymore. So it doesn't matter anymore how you start the building, it just matters whether you are holding shift or not at the moment, which makes it consistent with the normal entity building and the ghost icon. Once the topic is opened, it is hard to leave it so easily, so we agreed that the rail building could be streamlined even more. The current model is, that you have to build one straight piece of rail first, and then you can use the rail builder on the edge of that rail. It is annoying generally, and especially for the new players, because he might miss the way how it is being used, as the straight rails are built exactly the same way as other entities. The reason we did it this way was mainly, because when we first introduced the (new at that time) rail builder, we weren't confident enough that it could replace even the basic straight rail building. But since the rail building is stable enough, we might go one more step forward. The plan is that the rail won't be used to build straight rails normally the way you can now. The rail item would be always used to build by the rail planner only. Instead of having to snap to an existing rail, you could just start building anywhere on the ground. Instead of showing the rail preview when holding the item, you would see the arrow as when starting the rail building, and you could rotate it with the R key. It would make sense, to make the arrow color/size different for starting a rail planner on the ground versus snapping to an existing rail, but other than that, it would be the same.
Hello, we are still focusing most of our resources towards fixing as many bugs as possible so we have stable release in reasonable time. In the meantime, the preparation for the continuation of the work on the GUI rewrite is still happening:
Removing RTL language translations Wheybags I'm sorry to say that we have removed the RTL language translations (Hebrew and Arabic) in 0.17.20. Until this point we've had a half implementation of RTL languages, where the text is simply flipped when we download it from Crowdin. This 'works' for a decent proportion of things, but not nearly 100%. In order to attain the level of polish we want for the 1.0 release, we would need to spend a lot of time implementing proper support for RTL layouts. This just doesn't make sense for us given our current goals, and the proportion of our player base which uses these languages (less than 0.1%). We decided that instead of completely gutting the translations, we could leave them in for those who enjoy them, but not to offer them in the GUI as defaults. The languages will remain up on Crowdin, and the locale files will still be present in game, but there will be no option in the in-game language options dialog to choose them. If you want to use an RTL language, you will have to manually edit your config file to set your locale. Detailed instructions are available on our forum. What this also means, is that we won't be investigating any bug reports about RTL issues.
Playtesting kovarex We have been playtesting a few days this week. There were some things we had to fix on the fly, but we still were able to play quite a lot, so I would say that it went surprisingly well. We have been able to get 3 multiplayer bases into a late game stage.
The release plan (kovarex) This week was the time to close and finish all the things that will go to 0.17.0. Not all of the things that we originally planned to be done were done (surprise), but we just left any non-essential stuff for later so we won't postpone the release any further. The plan is, that next week will be dedicated to the office playtesting and bugfixing. Many would argue, that we could just release instantly and let the players find the bugs for us, but we want to fix the most obvious problems in-house to avoid too many duplicate bug reports and chaos after the release. Also, some potential bugs, like save corruptions, are much more easily worked on in-house. If the playtesting goes well, we will let you know next Friday, and if it is the case, we will aim to release the week starting 25th February.
It's the last Friday of 2018, and as such the last Friday Facts before the New year of 2019. We all hope everyone has had a great 2018, and looking forward to a lot more automation fun to come in 2019. Albert has produced a postcard for you all to share to give the year a good send-off.
Steam Awards (Klonan) Steam has opened up the nominations for this years Steam Awards. Last year Factorio was actually selected as a nominee for the 'Haunts My Dreams' award. There is a category this year for 'Best Developer', and many in the community have wanted to nominate us for that category. Unfortunately to be eligible, we would need to have a developer page set up on Steam. We had some discussions, and decided to wait until we have a final 'Wube Software' logo and theme finalized before setting up a developer page. This means you won't be able to vote for us as best developer this year... This doesn't meant that you can't nominate Factorio for one of the categories, and there has already been some discussion on the subreddit about which games people are voting for.
The modern biter (Albert, Ernestas) Besides vegetable and plant stuff, biters are the main population on the surface of the Factorio planet. They are the locals, and somehow, from a twisted perspective, they can even be considered the bad guys. Not anymore. The magic of high resolution gives us the chance to move deeper into their conceptualisation and we've added a new ingredient to their formulation: cute...-ish. For the last couple of weeks Ernestas and I have been working on the new version of the biters. Together we worked on developing the concept and ideas behind them, and Ernestas was doing the rest: modeling, texturing, shading, rigging, skinning, animating, rendering, post-processing, and being patient with me and my constant comments and changes. Cute is how we like them, we want you to feel sorry about planning massive biter massacres. In fact we want you to feel pity towards them, especially when you are killing them and destroying their habitat at industrial scale. But also we want you to be disgusted by them, because they are alien to you, and they need to look the part, so it is quite a complicated equation. Basically after the experience in-game with the classic version, we've learned what aspects of the biters are working well, and how to improve the parts which aren't. So we've decided to elongate their legs and accent their eyes in order to provide this more insectoid feeling. Also their new design is optimized for their attacks, they have 2 stronger front legs for providing destruction, 4 back legs to be able to run and stand during the attack, and stronger articulated mandibles to chew on your factories. In these animations we can fully see the potential of disgust, the way they move now is more insect-like, similar to a cockroach (many people are disgusted by cockroaches), and also we've balanced the animation loop with their speed in the game, so they shouldn't slide around. Keep in mind that this is still a work-in-progress and we have some more tweaks to do and extra animations to make, like their attack and death. We are also working on their sound design, and apart from that we might have some other surprises to make killing them extra gratifying to watch.
Scan-codes vs Key-codes (posila) While migrating from Allegro to SDL, HanziQ and Jiri replaced the keystroke handling from using key-codes to scan-codes. Before you start jumping with joy, you’ll probably wonder: What is that and why should I care? Well, funny you should ask. You probably won’t care, unless you live outside of USA and/or you use a non-US keyboard layout. In short, key-code is a key identifier dependant on the symbol the key will output when pressed, scan-code is a key identifier based on the physical location of a key. So for example players with French keyboard layout (AZERTY) have to jump to the control options after launching the game for the first time, and remap movement from WASD to ZQSD, in order to be able to move their character without hurting their hand. In 0.17, the controls will map to the correct keys by default, regardless of your layout, and stay mapped to those physical keys even if you for some reason change your keyboard layout while the game is running. The disadvantage is, most of the non-US layouts didn’t end up with completely broken controls, so people kept playing with them and got used to them. So they’ll need to get used to the layout the game was originally designed with, or manually configure controls back to what they are used to. But wait, there is a catch... A few weeks ago we have announced new construction tools, which are by default bound to quite universal shortcuts (Ctrl+C for copy, Ctrl+X for cut and Ctrl+Z for undo). Bilka pointed out that the German keyboard has Z swapped with Y (as does the Czech one, but developers often don't use it) and undo incorrectly defaults to Ctrl+Y instead. To fix these kind of shortcuts we determine the appropriate default scan-codes at start-up, so that undo is always Ctrl+Z, regardless of your layout, but the action will stay bound to those keys if you change keyboard layout at runtime, which is hopefully a reasonable compromise. We might do it for other controls too (it feels natural for M to always be the default key to open the map, and T to open the technology screen), but there is another catch. It is completely reasonable for player to walk north, and Ctrl+click some entities. Remember AZERTY keyboard? Player keeps Z pressed down to walk north and presses Ctrl to start control clicking. Well, I tested this and it doesn’t trigger undo, but still stops player from walking. So it is not completely destructive, rather annoying. I am not sure how or if we’ll solve this, perhaps people with these layouts that create these kind of collisions will need resolve them by changing controls options manually.
